Stalls during video playback are perhaps the most important indicator of a client's viewing experience. To provide the best possible service, a proactive network operator may therefore want to know the streaming clients' buffer conditions and use this information to help avoid stalls due to empty buffers. However, estimation of clients' buffer conditions is complicated by most streaming services being rate adaptive, and many of them also encrypted. Rate adaptation, implemented by HTTP-based Adaptive Streaming (HAS) clients, reduces the correlation between network throughput and client buffer conditions. Usage of HTTPS prevents operators from observing information related to individual requests for video chunks, such as indications of rate adaptation or other HTTP-level information.
To properly provision their networks, operators need to understand the characteristics of application traffic mix in addition to manage data volume demand. As networks go through low to high utilization phases, e.g. due to diurnal patterns, the users' Quality of Experience (QoE) may vary as data flows compete for bandwidth, especially in more constrained types of networks, such as those with wireless last mile. To provide users with high QoE when operating at moderate-to-high utilization, it is therefore important to understand user experience and real-time requirements associated with different network flows.
Currently, various flow classification techniques have been applied that map flows to the underlying services they provide. For example, by classifying flows into categories such as real-time streaming service and peer-to-peer downloads, network providers have been able to prioritize real-time streaming services at times when the more elastic demands of peer-to-peer networks have used up much of the available bandwidth. Since video streaming is responsible for the majority of today's network traffic, classifying all video flows into a single class (without further differentiation within this dominating class) is not much help.
There is a need to continually and individually classify flows based on their clients' current buffer conditions. Streaming clients often have highly heterogeneous real-time requirements, and these requirements typically change over the duration of a playback session. For example, streaming clients that have built up a large playback buffer may be highly tolerant to delays in receiving video data (e.g., compared to web clients that often expect immediate loading of websites), while clients with drained buffers may have tighter real-time requirements, in that they need additional video data sooner to avoid stalls (due to empty buffer events). In addition, the real-time requirements of a client may quickly change from critical to low priority, as the buffer builds up again. The importance of differentiating between these clients becomes particularly clear when considering that stalls (and their duration) is the factor that has the largest impact on clients' QoE.
The problem of classifying video streaming flows based on the clients' current buffer conditions (i.e., their current real-time requirements) is further complicated by high usage of HTTPS combined with rate adaptation in almost all popular streaming services. First, with HAS, each video quality encoding is typically split into smaller chunks that can be independently downloaded and played. The use of multiple encodings of each chunk allows efficient quality adaptation on the clients. This helps clients adapt to network conditions and reduce the number of playback stalls, but also decreases correlation between packet-level throughput and buffer conditions.
Second, increasingly many video streaming services, including YouTube and Netflix, deliver all or most of their content using HTTPS. Usage of HTTPS prevents operators from observing HTTP requests for video chunks and associated meta-data, restricting classifiers to TCP/IP packet-level information. This restriction presents additional challenges in the context of HAS, as the rate-adaptive nature of HAS complicates the relationship between packet-level throughput and buffer level conditions. As argued later in the paper, this challenge is further augmented in services such as YouTube, where different number of chunks may be requested simultaneously (e.g., using a single range request).
The disclosure includes examples addressing at least one of these problems.